home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_100 / 118_01 / changes.doc < prev    next >
Encoding:
Text File  |  1980-07-08  |  6.5 KB  |  207 lines
  1. .cm changes made to primitives
  2. .cm source:  changes.doc
  3. .cm version: October 15, 1981
  4. .bp 1
  5. .he 'changes.doc''%'
  6. .fo ''-#-''
  7.  
  8.    This file discusses changes that I made to
  9. adapt the primitives from the Software Tools Users Group
  10. to the environment of BDS C.
  11. As I mentioned in the file CONTENTS.DOC,
  12. these changes are not very satisfactory.
  13. The resulting primitives are compatible with neither
  14. the Software Tools Primitives nor the Unix primitives.
  15.  
  16.    However, many of the primitives supplied by the
  17. Software Tools Users Group have no analog in the
  18. Unix primitives.
  19. Thus, it will still pay you to look at the primitives
  20. and see what you can use.
  21.  
  22. .ul
  23. Changes made to BDSCIO.H
  24.  
  25.    All global definitions used by BDS C and the Software Tools
  26. have been combined into the file TOOLS.H.
  27. The following changes have been made to BDSCIO.H:
  28.  
  29. 1.  I have not included the constants for terminal
  30. characteristics, serial port characteristics or modem
  31. characteristics.
  32. I really don't see why these are needed in 
  33. .ul
  34. every
  35. program.
  36. However, the definition for ESC does appear in TOOLS.H.
  37.  
  38. 2.  The definition of MAXLINE has been moved so that it
  39. appears with all other constants which affect data structures.
  40.  
  41. 3.  Ditto for NSECTS, BUFSIZ and struct _buf.
  42.  
  43. 4.  Since the Software Tools assume that dynamic storage is
  44. available, I have removed the ALLOC_ON and ALLOC_OFF
  45. definitions.
  46. All tools compiled with TOOLS.H will have access to
  47. struct _header and the variables _base and _allocp.
  48. I think this is a reasonable scheme because there are lots
  49. of variables whose names start with either _ or SYS_.
  50. We might as well just prevent the user from using variables
  51. and functions which start with those characters.
  52. Another reason why this decision seems reasonable is that
  53. the dsinit() primitive makes it unnecessary for programs to
  54. access _base and _allocp directly.
  55.  
  56. .ul
  57. Changes made to RATDEF:
  58.  
  59. 1.  I have eliminated many of the definitions for ASCII
  60. control characters.
  61. This was done in an effort to control the number of 
  62. names that the system is supposed to define.
  63.  
  64. 2.  I have eliminated all of the definitions for individual
  65. letters.
  66. For instance, I see no reason to define BIGA as "A".
  67. In RATFOR, there is a reason, but not in C.
  68.  
  69. 3.  I have eliminated most, but not all, of the definitions
  70. for printable ASCII characters.
  71. I have kept only those characters that may not appear on
  72. most keyboards or which might be confusing inside quotes.
  73.  
  74. 4.  I have eliminated most RATFOR language extensions because
  75. they already are a part of C.
  76. Indeed, their purpose was to make RATFOR look more like C.
  77.  
  78. 5.  I have eliminated most of the "manifest constants".
  79. These are either unneeded or are duplicates of BDS C constants.
  80.  
  81. 6.  I have (reluctantly) kept most of the constants which
  82. affect the size of data structures.
  83. This is one area where having pointers eliminates a lot
  84. of Mickey Mouse declarations that do absolutely nothing.
  85. There is a real difference between:
  86.  
  87.     int vector[]      /* in C */
  88.  
  89. and
  90.  
  91.     integer vector (ARB)    # in RATFOR.
  92.  
  93. The diffence is that there are a lot fewer irrelevant names
  94. (I'm talking about ARB) to worry about.
  95.  
  96. 7.  I have eliminated the DRIVER and DRETURN macros.
  97. I don't know how to implement them in BDS C.
  98.  
  99. 8.  I have inserted declarations for variables used by
  100. my implementation of the primitives.
  101. These declarations are needed in TOOLS.H only because
  102. BDS C does not have STATIC variables.
  103.  
  104. .ul
  105. changes to BDS C routines
  106.  
  107.    The names
  108. of several BDS C routines conflict with the names
  109. of the primitives used by the Software Tools.
  110.  
  111.    The following BDS C routines were changed by prefixing
  112. them with an underscore character:
  113.  
  114. close, creat,
  115. exit,
  116. fclose, fcreat, fflush, fopen, flush,
  117. getc, gets, getchar,
  118. open,
  119. putc, puts, putchar,
  120. read,
  121. rename, 
  122. rcfsiz, rreed, rseek, rsrec, rtell, rwrite
  123. seek,
  124. ungetch, unlink,
  125. write
  126.  
  127.    The routines getc(), putc(), and ungetc() are now defined on
  128. file FILE.BDS rather than on STDLIB1.C.
  129. These routines had to be completely rewritten to allow for
  130. I/O redirection.
  131.  
  132.    Some other changes were made to the code in TOOLIB1.BDS
  133. to allow for I/O redirection.
  134. See that file for more details.
  135.  
  136. .ul
  137. Changes made to the Software Tools Primitives
  138.  
  139. 1.  The calling sequence of getch() was changed.
  140.  
  141. old calling sequence:  c = getch (unit, &c)
  142.  
  143. new calling sequence:  c = getch (unit)
  144.  
  145. The change was made because the old calling sequence is
  146. awkward in a C environment.
  147. The old sequence was used because the following is not
  148. legal in a RATFOR environment:
  149.  
  150.     while ((c = getch(unit)) != EOF) {
  151.  
  152. 2.  The calling sequence of getarg() was changed.
  153.  
  154. old calling sequence:  arg = getarg (n)
  155.  
  156. new calling sequence:  p = getarg (n)
  157.  
  158. In other words, the new version of getarg() returns a pointer
  159. to the argument where the old version copied the argument.
  160. The change was made because there is no need for getarg
  161. to actually copy an argument.
  162. Returning a pointer to an arg is more natural in C.
  163.  
  164. 3.  Getwrd() changes one of its parameters.
  165. Thus, the calling sequence must be:
  166.  
  167.     j = getwrd (in, &i, out);
  168.  
  169. 4.  The old definition of type() is absurd.
  170. There is, in fact, not much use for this "primitive" in C.
  171. I suggest that type() return "a" for alphabetic characters,
  172. "0" for numeric characters, and the character itself for all
  173. other characters.
  174. See STRING.BDS for the new definition of type().
  175.  
  176. 5.  Stcopy() changes one of its parameters.
  177. Thus, the calling sequence must be:
  178.  
  179.     stcopy (from, i, to, &j);
  180.  
  181. 6.  The C version of index must return one less than the
  182. RATFOR version of index because C arrays start at 0, not 1.
  183.  
  184. 7.  The length() primitive in RATFOR is a duplicate of the
  185. BDS C strlen() routine.
  186.  
  187. 8.  The RATFOR ctoi() routine changes one of its arguments.
  188. Thus, the calling sequence must be:
  189.  
  190.     ctoi (string, &i);
  191.  
  192. 9.  I have not examined (or converted) many of the routines
  193. in CONVERT.BDS or PATTERN.BDS.
  194. I can't say for sure what may have to be done.
  195. However, many of the routines in PATTERN.BDS change
  196. their arguments.
  197. Thus, the calling sequences for these routines will have
  198. to contain the & character.
  199.  
  200. 10.  As I have said before, I don't exactly know what to
  201. do with the routines in SYMTAB.BDS.
  202. The routines there do work, but they assume that the
  203. information field associated with a symbol is a string
  204. terminated by an EOS.
  205. This is not a very good way to design an important primitive.
  206. See the comments and code in SYMTAB.BDS for more details.
  207.